home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 279 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  2.7 KB
  1. Path: engnews1.Eng.Sun.COM!taumet!clamage
  2. From: thp@cs.ucr.edu (Tom Payne)
  3. Newsgroups: comp.std.c++
  4. Subject: Re: Throwing an exception from within a signal handler
  5. Date: 4 Feb 1996 18:28:44 GMT
  6. Organization: University of California, Riverside Department of Computer Science
  7. Approved: clamage@eng.sun.com (comp.std.c++)
  8. Message-ID: <4f2th6$4qh@galaxy.ucr.edu>
  9. References: <4dgj4m$9la@engnews1.Eng.Sun.COM> <DLCosx.Hn1@falcon.daytonoh.attgis.com>
  10. NNTP-Posting-Host: taumet.eng.sun.com
  11. Content-Type: text
  12. X-Nntp-Posting-Host: corvette.ucr.edu
  13. X-Newsreader: TIN [UNIX 1.3 950824BETA PL0]
  14. Content-Length: 2075
  15. Originator: clamage@taumet
  16.  
  17. J. Kanze (kanze@gabi.gabi-soft.fr) wrote:
  18. : In article <4ebptg$frt@galaxy.ucr.edu> thp@cs.ucr.edu (Tom Payne)
  19. : writes:
  20. : 
  21. : > : From ISO 9899, section 7.7.1.1: ``If the signal occurs other than as the
  22. : > : result of calling the abort or raise function, the behavior is undefined
  23. : > : if the signal handler calls any function in the standard library other
  24. : > : than the signal function itself (with a first argument of the signal
  25. : > : number corresponding to the signal tha caused the invocation of the
  26. : > : handler) or refers to any object with static storage duration other than
  27. : > : by assigning a value to a static storage duration variable of type
  28. : > : volatile sig_atomic_t.''
  29. : > [...]
  30. : > 
  31. : > In other words, the only asynchronous activity allowed to programs
  32. : > with defined behavior is polling volatile atomic variables that are
  33. : > set by signal handlers.  Thus far, no one has given me a reason for
  34. : > prohibiting signal handlers from reading volatile atomic variables,
  35. : > which is a common practice in interrupt handlers (even those written
  36. : > in C/C++).
  37. : 
  38. : Correct.  In practice, I cannot conceive of an implementation where
  39. : writing something would be atomic, but reading it wouldn't.  On the
  40. : other hand, read/modify/write will frequently not be atomic.  And why
  41. : else might you want to read an object in a signal handler, if not to
  42. : modify it?
  43.  
  44. Atomicity of such updates to atomic variables is not always a problem.
  45. For instance, in most cases a signal handler can increment an atomic
  46. counter (e.g. a timer) without difficulties, even though the
  47. read/modify/write sequence is not atomic.  In the case of nonatomic
  48. variables, atomicity must be enforced by blocking certain signals.
  49. Such blockage could be portably implemented via atomic blockage flags,
  50. which, in turn, are volatile atomic variables that must be read by
  51. signal handers.
  52.  
  53. Tom Payne  (thp@cs.ucr.edu)
  54.  
  55. [ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  56.   Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy is
  57.   summarized in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
  58. ]
  59.